The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Modern computer networks rely on routers, proxy devices, switches and other infrastructure elements that act as the intermediary devices that connect clients to a destination server. Clients establish connections to the intermediary, which then establishes a connection to the destination server. The intermediary device sends data received from the client to the destination server and forwards data received from the destination server to the client. The intermediary device acts as both a server and a client. It is a server to its client and a client to its destination server.
FIG. 1A illustrates a network using proxy 102 as an intermediary between clients 104, 106 and server 108. Proxy 102 can be configured to perform a variety of functions before sending a segment of data to the server 108; such functions include, for example, Network Address Translation, Firewall protection or executing a software application to perform an operation on data carried in the segment.
In a typical network implementation, the proxy 102 has one connection to clients 104, 106 and another connection to the server 108. When client 104 sends a request, proxy 102 forwards the request on to the server 108 after the proxy 102 performs its intended function. Similarly, the response from server 108 is sent to proxy 102, and is forwarded back to the client 104. A client 104 may have explicit configuration identifying which proxy it should use. The proxy 102 uses its own network address when connecting to the server.
When a proxy has been configured to function as an explicit proxy, meaning that the proxy uses its own network address to connect to at least one connection (the client or the server) the connection must be explicitly configured to connect to the proxy. For example, in FIG. 1A proxy 102, acting as an explicit proxy, requires that every client 104, 106 must be explicitly configured to connect to proxy 102. Typically a configuration setting in client 104, 106 must be manually set to reflect a network address of the proxy 102. Requiring a configuration for every connection is very problematic for large-scale networks.
Similarly, when a firewall 112 is placed between the clients 102, 104 and server 108, so the firewall 112 can inspect all inbound and outbound traffic, as seen in FIG. 1B, client configuration is required. The clients 104 and 106 must still be configured to know about proxy 102; otherwise, traffic will just pass though the firewall 112 and completely ignore proxy 102. A firewall is a special type of router that enforces security policies when moving packets from one network to another. In contrast, in a transparent proxy arrangement, no configuration change is needed at the client side.
Another problem arises in the approaches of FIG. 1A and FIG. 1B when proxy 102 uses its own network address to access server 108. For example, proxy 102 receives two connections, one from client 104 and the other from client 106. As a result, the server 108 sees two requests from a single host proxy 102. The process performed by the proxy 102 is similar in effect to performing PAT (Port Address Translation). PAT is described further in “Configuring Network Address Translation and Static Port Address Translation to Support an Internal Web Server,” document ID 12095, from Cisco Systems, Inc., San Jose, Calif. A PAT policy in many cases contradicts with other explicit NAT (Network Address Translation) policies that a user would have configured. A PAT policy also potentially creates problems for other firewall, quality of service, and virtual private network devices that are deployed between the proxy and the server.
When a router or firewall is deployed in “virtual mode,” which means it simulates multiple virtual or logical devices on a single hardware device, it often puts great contraints on how/where the explicit proxy 102 should be deployed. For example, assume user designs a virtual router/firewall between network-1 and network-2, and another one between network-3 and network-4. The physical device may classify a network packet to the proper virtual router/firewall by its receiver interface, NAT configuration, and destination MAC, etc. When an explicit proxy is to be deployed for all traffic, user would face a tough design issue on where to put it. Assume he creates a network-5 to host the proxy, he would have traffic from network-1<->network-5<->network-2, and network-3<->network-5<->network-4. This creates two issues. First the original segregated traffic (network-1<->network-2, and network-3<->network-4) are now being mixed in network-5. Secondly packets are now traversing 2 network boundaries, e.g. network-1 to network-5, then network-5 to network-2, each boundary needs its own virtual router/firewall which means user has to double the number of virtual router/firewall configured on his device.
In many cases valuable stream-based applications such as file-based anti-virus scanning cannot be enabled due to the PAT policy. For example, a packet upon arrival at a router is classified into a connection based on information such as the receiver interface, NAT configuration, and destination MAC addresses. Based on the packet classification, the router retrieves the security policy configured for that specific combination of values. If the packet is then diverted to a proxy 102 for processing at a proxy application, under standard IP routing approaches the router cannot re-classify a packet received back from the proxy since the original information used to classify the packet has been discarded at the proxy or proxy application. Thus once the packet is injected back from the proxy, the valuable classification by router 112 is lost.
One prior approach merges the network nodes, such as routers, and proxy application into one machine. In this approach the proxy application is compiled into an existing network node's operating system. However, in many cases the network node's operating system is configured such that it is difficult to incorporate an application software on top of the operating system, thus requiring extensive modification to the software in order to make it compatible with the operating system. Furthermore, by incorporating the operating system with routing logic and proxy application into one machine, all such elements must share CPU time and memory, potentially causing resource starvation. It is much more efficient and beneficial to keep these two components separate.
Another approach used to avoid the re-classification problem resulting from PAT involves a transparent proxy. In a transparent proxy the client is unaware of the proxy and always addresses packets to the server. The proxy intercepts and spoofs the connection. When the proxy connects to the server, the proxy spoofs the client's IP address and port values. Thus none of the client's information is lost upon transfer. Referring to FIG. 1A for illustration purposes, the server will receive one connection coming from client 104 and another connection coming from client 106. The proxy is “invisible” to both the client and the server.
However, in many situations the proxy and proxy application are configured such that they are explicitly set to be an explicit proxy, or require, at minimum, the use of the proxy's IP address for at least one connection, therefore preventing transparency.